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Abstract 


Energy management in households gets increasingly more attention in the struggle to 
integrate more sustainable energy sources. Especially in the electrical system, smart 
grid systems are envisioned to be part in the efforts towards a better utilisation of the 
energy production and distribution infrastructure. The Home Energy Management 
System (HEMS) is a critical infrastructure component in this endeavour. Its main goal 
is to enable energy services utilising smart devices in the households based on the 
interest of the residential consumers and external actors. With the role of being both 
an essential link in the communication infrastructure for balancing the electrical grid 
and a surveillance unit in private homes, security and privacy become essential to 
address. In this chapter, we identify and address potential threats Home Energy Man- 
agement Platform (HEMP) developers should consider in the progress of designing 
architecture, selecting hardware and building software. Our approach starts with a 
general view of the involved stakeholders and the HEMS. Given the system over- 
view, a threat model is constructed from the HEMP developer's point of view. Based 
on the threats that have been detected, possible mitigation strategies are proposed 
taking into account the state of the art of technology for securing platforms. 


Keywords: smart grid, IoT, security, privacy, cloud, web service, service-oriented ar- 
chitecture 


1. Introduction 


A smart grid is a vision of a more intelligent electrical infrastructure. It is envisioned to provide 
a more reliable and effective electrical grid in the process of integrating more intermittent 
renewable energy sources, like wind power and solar power. This will demand for systems that 
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will continuously monitor and manage end-points of the grid, for example, an end-point as the 
residential sector that consumes around 31% of the electricity worldwide [1]. These systems are 
known as Energy Management Systems (EMSs). EMSs aim at utilising the grid capacity more 
efficiently in terms of instantaneous demand and generation. This includes flattening the peak 
demand by giving the demand-side awareness about the time periods it is “smart” to con- 
sume energy [2]. 


Ensuring security and privacy are becoming important issues to address with the deployment 
of smart meters. Smart meters are devices that record the electric consumption and production 
and communicates this information automatically to the utility. Research has shown that 
information from smart meters can reveal personal habits and disclose details about the 
residents living there. Furthermore, the situation exacerbates if additional meters and actuators 
are installed on the most consuming devices for Direct Load Control (DLC) in the demand 
response paradigm. Therefore, security and privacy enhanced system architectures suggest, a 
Home Energy Management System (HEMS) that runs locally inside the residential home, 
among other things to resolve privacy issues. 


Service Service Service 


Service platform 


Service framework 


Home energy 


management platform Application virtualization software 


Operating system 


O Layer 


@ Optional layer Hardware 


Figure 1. The considered stack for a HEMS. 


This chapter describes security and privacy issues for a HEMS in an SOA. It focuses on the 
Home Energy Management Platform (HEMP) provider [also in other contexts referred to as 
the Original Equipment Manufacturer (OEM)]. A HEMP provider is responsible for the 
platform, which the software developers and service providers can deploy their software and 
services on as seen in Figure 1. A HEMP provider creates the platform that facilitates security 
and privacy in several layers. Following a holistic approach, a threat modelling approach is 
used that considers the interdependencies between stakeholders of the system before identi- 
fying the threats the system faces. A risk assessment is made on the identified threats, and 


1 Percentage based on the average electricity consumption from residential domains in Spain, Norway and Denmark. 


?EMSs can refer to not only systems that support the operation of the electrical grid on a transmission and distribution level 
but also systems that automatically control and monitor energy usage in buildings. 
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possible mitigation strategies are presented based on a review of the state of the art in hardware 
security. Based on the threat analysis, recommendations to create a secure HEMS are provided. 


2. Background and related work 


A preliminary review of the domain is presented before developing a threat model for the 
HEMP. The review includes a description of general threat modelling approaches together 
with commonly used diagrams to perform the analysis. 


2.1. Threat modelling approaches 


Threat modelling is a systematic approach that supports the process of finding the appropriate 
technical solutions for enforcing security and privacy. It considers the potential threats with 
the greatest impact and addresses these first. 


There are generally three approaches to threat modelling [3]: 


e Assets-centric: Assets define things that need protection, or things the attacker wants or 
something in between those two. The approach focusses on defining the assets of the system 
and afterwards, analysing the flow of assets within an organisation. The model can then be 
applied with an attack set like STRIDE [3], which is a mnemonic for Spoofing, Tampering, 
Repudiation, Information disclosure, Denial of service and Elevation of Privilege. 


e Attacker-centric: Envisioned attackers are defined in terms of resources and capabilities. 
An attacker model identifies a number of scenarios where an attacker can break the system 
both directly and indirectly. Directly, in terms of exploiting, for example, software vulner- 
abilities, and indirectly, in terms of exploiting humans that have privileges within the 
system. 


e System-centric: The approach attempts to look at the designed system as a whole. As the 
system is being designed, the threat model is continuously being developed or updated. 
The threat model includes finding threats using, for example, STRIDE and attack trees [3]. 


When comparing the approaches, the system-centric approach more tightly couples with the 
development process, whereas the asset-centric approach and attacker-centric approach can 
be considered more “detached” and are typically performed separate from the software 
development. 


2.1.1. Diagrams for threat modelling 


The typical diagrams for revealing threats focus on describing the domain or the data flows 
within the considered system. The goals of these diagrams are to create a common view of the 
system and to make the communication paths visible. These diagrams provide an abstraction 


3 Is often called software-centric, but for the sake of generality we use the term system-centric. 
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of the system which allows system architects and software developers to create a common 
view of the system and define the system boundaries. 


The Unified Modelling Language (UML) [4] is general-purpose modelling language that 
specifies a set of diagrams for modelling systems. It provides a standardised way of modelling 
systems and provides two fundamental representations of a system: behavioural models and 
structural models. Behavioural models, such as use case diagrams, can be beneficial to identify 
stakeholders and describe a proposed functionality. Structural models, such as class diagrams, 
are useful for describing the domain which includes objects, attributions, operations and 
relationships. 


Data Flow Diagrams (DFDs) have traditionally been used for threat modelling, since the threat 
problems tend to follow the data flow not the control flow [3]. It is used for describing how 
data enter and leave the system. The basic elements for modelling the system are shown in 
Table 1. The system is typically modelled with specific scope, where the external system that 
provides the system with data is modelled using the external entity element. The system of 
interest consists of a number of processes and data stores with data flow between them. To define 
the boundary between trust elements and non-trusted elements, DFD also includes trust 
boundaries. Trust boundaries visualise where data flows intersect between the system and a 
malicious actor. 


Element Model Description Examples 


External entity Outside scope A stakeholder delivering or receiving 


External to the system 


entity 


Process Execution of system element Executable code or hardware function 
Data flow Communication between RPC calls, system calls, HTTP 
elements 
Data flow 
Data store 7 Entity that stores data Files, memory, database 
Data siore 


Table 1. The basic elements of a DFD. 


By modelling the specific system with DFD elements, it is possible to map these elements to 
the STRIDE threats. For instance, an external entity for the system can generate a spoofing threat, 
that is, an external entity can pretend to be something or someone else than originally thought 
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of. By enforcing an authentication mechanism, it is possible to mitigate the threat if the external 
entity was trying to spoof a person or a thing. 


2.2. Home energy management software platforms 


As depicted in Figure 1, the HEMS consists of a software platform that provides the middle- 
ware for interoperable communication between devices and services. In the following, two 
open source EMSs are presented. Both use the OSGi (Open Service Gateway Initiative) 
architecture that specifies a modular and service-based software platform implemented in 
Java. 


2.2.1. OpenHAB 


The openHAB project’ is an open software framework that focusses on enabling home 
automation by joining systems and technologies available in the smart home domain. It allows 
for automation rules and offers a single user interface for all such systems. The openHAB 
software is capable of running on any device that supports the Java Virtual Machine (JVM). 
The architecture consists of three main components: the OSGi framework, openHAB Core 
Components and openHAB Add-ons. The OSGi framework and the openHAB Core Compo- 
nents represent the internal communication infrastructure and base libraries. The openHAB 
Add-ons include a large set of protocol bindings that map between other home automation 
protocols to an abstract data model. It includes an “item” repository, where an item can be 
interpreted as an abstraction for a property a device can actuate. The openHAB framework 
provides mechanisms for securing the communication to the openHAB software platform, but 
does not have additional security features beside what the OSGi framework can provide. 


2.2.2. OGEMA 


Open Gateway Energy Management (OGEMA) is an open software framework for smart grid 
services. It represents a system that supports building automation control and energy man- 
agement for residential and industrial environments. The framework rests on a hardware- 
independent platform with a common execution environment for all deployable services. 
OGEMA uses the OSGi Java framework enabling a modular and dynamic software environ- 
ment. The OGEMA framework consists of the following entities: 


e OGEMA Services: Common services like resource administration, user interface, web 
interface and data logging, but also a common data model and access control. 


e Resources: Data structures according to the data model representing the connected devices. 
° Applications: Services for, for example, price-based management and energy analysis. 


° Communication drivers: Drivers for supporting multiple communication media, for 
example, ZigBee and EEBus. 


* http://www.openhab.org/ 
> http://www.ogema.org/ 
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The OGEMA architecture embeds three “modes” of security: standard infrastructure, a 
controlled environment and proof of security [5]. Furthermore, it isolates third-party applica- 
tions which can be integrity checked using the public key of the service provider. This is similar 
to Android's permission handling [5]. Since OGEMA framework is restricted to security 
capability of the OSGi Java framework and the JVM, it is possible for a malicious component 
to freeze the platform by allocating too much memory or changing shared variables. A possible 
solution to this issue is the I-JVM presented in [6]. 


2.3. Threat analysis of the smart grid domain 


Cyber-Physical Systems (CPSs) and Internet of Things (loTs) are two research domains that 
overlap and share similar challenges with the smart grid domain. In [7], they identify four key 
challenges in designing a secure IoT which include data management, identity management, 
trust management and privacy. Based on these challenges, they propose hardware-based 
mitigation strategies that include Physical Unclonable Function (PUF) for data provenance, 
integrity and identity management. However, they present a non-systematic approach where 
the stakeholders are not clearly identified. In reference [8], they consider threat modelling 
issues of CPSs. The authors provide a generic model of a CPS and present a case study with a 
road vehicle. In reference [9], researchers present a survey of security theories, analysis, 
simulation and application fields but without giving recommendations. 


In reference [10], they present a structured method for identifying security threats in smart 
home scenarios. It is based on a context pattern for the elicitation of domain knowledge for the 
smart home domain. Using the context pattern for creating DFDs for the smart domain, they 
identify the entry points and vulnerabilities. This allows them to define the attack paths from 
entry point to the assets of the system. Their method is sound and structured but lacks possible 
threat mitigation strategies. 


3. Threat modelling of a home energy management platform 


Security experts are encouraging designers to make explicit statements about the security 
assumptions, when designing and implementing systems. Defining the security assumptions 
is the first step in order to find the vulnerabilities of a system. With a description of the 
vulnerabilities, it is possible to assess the risks a given design exposes. Security technologies 
can then be enforced where the vulnerabilities need to be addressed. 


3.1. Methodology 


A systematic approach is necessary to discover all the vulnerabilities of a system [10]. Our 
approach for designing a HEMP is shown in Figure 2, consisting of five steps. The methodology 
is based on the work presented in references [3, 10, 11], but adapted to our work. 
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Figure 2. The methodology for performing the threat modelling. 


The following gives a description of the six steps in our method: 


Step 1. Define context and objectives — The context represents the identification of the main 
stakeholders of the system, the general system architecture and the desired objectives. The 
purpose of this step is to create the scope of interest and focus on the analysis. Part of the 
context is the review of regulations with the smart grid area and to describe the considered 
use cases. This includes also defining the dependency between stakeholders. With the 
definition of the context and objectives, requirements can be elicited. 


Step 2. Define DFD— Using the previously defined context, the flow of information is 
modelled through DFDs. Context elements are mapped to elements that present input/output, 
processes, data flow and data storage. In the modelling process, the context can be refined, for 
example, adding additional stakeholders or modifying the system architecture. Furthermore, 
it supports the process of modelling the domain knowledge to DFD elements. With the process 
of defining the context and modelling, the DFD represent the high-level system description. 


Step 3. Identify assets and vulnerabilitiesbased on DFD elements —Based on the DFD 
elements representing the HEMP, the system's assets and threats are identified. Assets 
represent valuable targets for an attacker and are therefore of interest for the attacker. Assets 
can be both physical and linked to a process. One approach to identify threats for the identified 
assets is the STRIDE-per-element or STRIDE-per-interaction approach [3]. 


Step 4. Risk impact assessment based on attack trees — With explicit threats, the risk impact 
assessment can be performed using attack trees. The step assesses how noticeable and with 
what likelihood a threat is. The outcome of this assessment can be either accepted or mitigated 
using a technical solution. An accepted risk represents a possible attack, but it is typically 
regarded as unlikely. 


Step 5. Selection of mitigation approach—If a threat is unacceptable, a selection of a mitiga- 
tion solution must be considered. The solution can be based on possible software or hardware 
technologies that consider an attacker with the same power or more. Mitigation can require a 
different hardware or software solution. The risk assessment of the threat can help in deter- 
mining the threat mitigation should be placed in the hardware or software. 
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3.2. Stakeholders, system architecture and objectives 


In Figure 3, the major stakeholders of the HEMS are presented. The residential consumer 
enables the deployment of HEMSs. Trust to the system, reduction of/control of electricity bills, 
addressing environmental concerns and better comfort (i.e., provision of technical solutions 
for better control of own energy use) are the main motivational factors for the residential 
consumers to adopt a smart grid solution [12]. Smart device vendors build sensors and 
actuators deployed in homes, for example, Wink,’ SmartThings’ or Vera’ represent an envi- 
sioned smart device vendor. Often these vendors can be categorised whether or not they 
provide a total home automation solution or have upgraded an existing product to be IoT- 
enabled. In the envisioned system, the Distribution System Operator (grid operator) is not 
directly interacting with the HEMS, instead it depends on the smart grid services developed 
by service providers and deployed by the service market responsible. Services utilise infor- 
mation retrieved from the residential homes and electric grid, to improve electricity usage for 
both the residential consumers and grid operator. For connecting the services and the smart 
devices, a communication service provider (CSP) is needed. The software platform providers 
create the software platform, where services can be executed. 


Service Grid 
Developers Responsible 


i A x 3 


Smart Device 


Service Market “~~ + 
k endors 
Responsible Home Energy 
Management System ie 


e- 7 \ a 


Communication rere N Consumers 
Service Provider ' ' 
Software Platform | HEMP ' 
Developers ' Developers | 


’ 


Figure 3. Overview of the major stakeholders of the HEMS. It is inspired by [32]. 


The HEMS is considered to be placed in an SOA, where there exist home-oriented and grid- 
oriented services. The services are implemented as web services based on the REpresentational 


€ http://www.wink.com/ 
7 https://www.smartthings.com/ 


8 http://getvera.com/ 
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State Transfer (REST) architectural style. The system considers many-to-one mapping between 
the residential consumer and the DSO, that is, the home-oriented services are executed for each 
residential consumer, whereas the grid-oriented services utilise the output for optimising the 
operation for the DSO. 


The rationale of the system architecture is that the home-oriented services will optimise 
according to demands of individual homes, whereas the grid-oriented services will support 
the operation of the electrical grid. Since grid-oriented services can be highly valuable for the 
grid responsible (DSO), these will foster the development of the home-oriented services. A 
fundamental requirement for the approach is that the services can be used as building blocks 
for delivering additional services. For a more detailed insight into the system, the reader is 
referred to references [13, 14]. 


The main characteristics of a service-oriented system are [15]: 
e Heterogeneous platform and execution environment. 
° Communication is handled through standards. 


e Advances the concept of component-based software by reducing the coupling between 
services. 


e Encourage continuous and independent (re)deployment of software. 


The domain model is depicted in Figure 4 using a UML class diagram together with the main 
stakeholders. It is composed of classes (rectangular icons), packages (folder icons) and actors 
(stick figures). It considers the domain to consist of two major parts: a service market and a 
residential home. Both parts include a number of elements (represented as classes) that represent 
the implementation by a stakeholder. At this stage, only elements that are relevant for an 
identified stakeholder are considered. The relationship between the elements indicates the 
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Figure 4. Domain model of the system. 
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multiplicity and type of association. Besides the basic UML arrows representing the associa- 
tions, two other arrows are drawn. The dependency between the stakeholders is modelled 
with an open arrow to visualise how stakeholder's business objectives are associated with other 
stakeholders. A closed arrow indicates the realisation of the element. 


In the process of defining hardware recommendations for the HEMP developer, focus is set 
on the HEMP developer as depicted and highlighted in Figure 3. As seen in Figure 4, the HEMP 
developer has several dependencies —either directly or indirectly. 


To this end, the objective of the HEMP developer for the HEMS is the following: 


The HEMP will provide a security and privacy enhanced platform for service developers 
to deploy on web service on, while being a trustworthy platform for the residential 
consumers, service providers and the grid responsible. 


3.3. Requirements 


To identify the security threats and vulnerabilities of the HEMP (see Section 3.5), the necessary 
requirements, which the platform must adhere to, have to be explicitly stated. An explicit set 
of requirements can guide the process of designing a platform which is resistant to possible 
attacks. Furthermore, it allows for a risk assessment of third-party services installed on the 
device. 


Requirements are usually understood as stating what a system is supposed to do—contrary to 
how it should do it [16]. It characterises the desired functional behaviour and performance, 
whereas non-functional requirements aim at fulfilling a desired property. Non-functional 
requirements are usually judged by the operator of the system and relate more to the system 
architecture, whereas functional requirements are testable. 


In the following, both the functional and non-functional requirements for the HEMP will be 
presented. The requirements are classified according to the direct stakeholders for the HEMP 
developer. The rationale is that the requirements and dependencies from the stakeholders will 
have an impact on the threats and thereby on the mitigation strategies that technical solutions 
can provide. The listed requirements are derived from use cases and requirements specified 
in references [14, 17-19]. 


3.3.1. Software platform developer 


Anessential feature of the HEMS is to provide an environment for executing services relevant 
for external actors in the smart grid. This includes services with real-time dependencies or not. 
These services can be manufactured by different service providers and therefore depend on 
an isolated execution environment, if a single service should not crash the system. Moreover, 
software trends dictate a continuous development and maintenance process to follow an agile 
development life cycle and fix newly discovered vulnerabilities. Thus, doing updates to the 
services is vital for its sustainability. Finally, a software platform is responsible for delivering 
the “knobs” of the smart devices for services and external system to interact with in a secure 
way. The requirements are as follows: 
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R1. The HEMS shall support execution of real-time dependent services, like services for 
controlling a residential battery according to external signals. 


R2. The HEMS employ separation mechanisms to securely isolate services. 
R3. The HEMS shall be able to upgrade existing services. 


R4. The HEMS shall support remote software updates from the software framework devel- 
opers for managing services. 


R5. The HEMS shall provide security measures appropriate for the protection of integrity and 
confidentiality of services. 


These requirements relate to service providers which represent the main stakeholder of the 
software platform developer. 


3.3.2. Smart device vendor 


End devices in the smart grids often represent the load of the electrical system. Giving these 
devices the ability to communicate with other devices facilitates information to be dissemi- 
nated to all stakeholders. For the smart devices to be part of the smart grid, a communication 
infrastructure in the Home Area Network (HAN) that incorporates a heterogeneous set of 
communication protocols is essential [20, 21]. Furthermore, for smart devices to provide a 
secure communication path, it is necessary to enable end-to-end encryption. The smart device 
vendors’ requirements are as follows: 


R1. The HEMS shall support multiple communication protocols for the HAN. 


R2. The HEMS shall provide smart device vendors with the ability to extend the set of 
communication drivers easily. 


R3. The HEMS shall facilitate end-to-end encryption between smart devices and the services 
that utilise and control the smart devices. 


Besides depending on the physical communication technology implemented on the HEMS, 
software drivers are also necessary to provide an interface for a service. 


3.3.3. Residential consumer 


The intelligent automation of the smart grid depends on the residential consumers. They will 
be an integral part that will ensure reliability of the electrical grid by modifying the way energy 
is used. A HEMS can support the behavioural change but requires the acceptance of the 
residential consumer. It is generally believed that a user-centric approach is vital, where trust 
to the system remains one of the priorities [12]. The requirements for a residential consumer 
are: 


R1. The HEMS must secure the confidentially and integrity of meter data. 


R2. The HEMS should provide residential consumers the ability to install and uninstall services 
on demand. 
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3.4. Data flow diagram of the home energy management platform 


The main purpose of DFDs is to identify the key data flows in the system. Modelling the data 
flows, contrary to the control flows, reveals how information is exchanged throughout the 
system. A DFD model explains who takes part in a process for delivering the information, the 
information needed to complete a process and what information is stored. 


Figure 5 provides an overview of the internal data flows ona HEMS and the HEMS interactions 
with the external entities based on reference [14]. Besides the DFD symbols presented in 
Table 1, the DFD is annotated with dotted lines indicating the trust boundaries. These are 
quantified three trust levels from the HEMP provider's point of view. Furthermore, it contains 
dotted arrows between processes, to indicate how a process affects another process's runtime. 
These are useful for expressing hardware-related issues. 
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Figure 5. DFD of the HEMS. 


As seen in Figure 5, seven processes are included in the model. This includes two services: 
third-party HEM service and a Meter Data Management (MDM) service. The MDM service is 
explicitly included to show the data flow of meter data and storage of the smart device 
configurations. The third-party HEM service presents any high-level service useful for smart 
grid operations. The service manager and software framework manager relate to the contin- 
uous maintenance of the software on the HEMS. Lastly, there is a system manager and device 
manager for the physical interaction with the HEMS. 


3.5. Threat analysis 


A threat model is a depiction of a system's attack surface. An attack surface has numerous 
threats towards a set of assets within the system. The purpose of mitigation techniques is to 
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protect the assets from a possible attacker. The envisioned attacker can be assigned capabilities, 
such as being able to have physical access to the system or only have access through the 
network. Other attackers include social engineers which through “social” interaction can gain 
unauthorised privileges to the system. This could be attackers using phishing emails to exploit 
vulnerable code in installed software. 


The threats for the HEMP provider are a combination of the indirect threats that the software 
platform provider faces and the external entities that have physical access to the HEMS. In the 
following, we classify the considered attacker, identify the assets of the HEMS and elicit a 
subset of vulnerabilities. 


3.5.1. Assets of the HEMS 


Assets represent valuable targets for an attacker, and therefore naturally represent the system 
susceptibility for threats. In the following, the key assets are identified with a description of 
the reason for its inclusion: 


Services: These represent both value-added services for the residential consumer, but also 
account for the foundation of service market generation. A compromised service can lead to 
cyber attacks on homely property. Furthermore, it can also lead to violation of the intellectual 
property for the service provider, thus undermining a service market. The services are 
dependent on the software platform provider to secure the services, where it assumes the 
underlying software stack (e.g., virtual machine, Operating System (OS), etc.) will not be 
compromised. The services can contain a range of sensible information regarding the residen- 
tial consumer, for example, granular meter data, personal identifiable information, crypto- 
graphic key sets and so on. 


Service manager: This process is responsible for presenting, installing, updating and unin- 
stalling services on the HEMS. It is in direct contact with the residential consumer and service 
market provider. An attack on the service market manager can lead to undermining the service 
ecosystem with services unable to be update if a critical software patch needs to be installed. 
It depends on the given privileges from the software platform. It contains the audit of installed 
services and cryptographic keys to allow for a secure connection to the smart market provider. 


System manager: This manager administrates the OS stack including middleware software 
(JVM, Python interpreter), system libraries and kernel (network interface, memory manage- 
ment, I/O interface, etc.), and therefore performs privileged operations. The entire software 
framework stack depends on its implementation. Therefore, it is assumed that it is configured 
and maintained reliably. 


3.5.2. Identifying vulnerabilities 


Vulnerabilities represent an attacker's entry points to the system. It is therefore crucial to 
identify these entry points in order to mitigate possible attacks. Here the vulnerabilities are 
presented using the STRIDE-per-interaction approach between the service and service 
manager. Other interactions identified in the DFD are omitted for brevity. 
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3.5.2.1. Services/service manager 


T1. Spoofing: The HEMS contacts the service market provider for exploring, installing, 
updating the services on Smart Market provider. If the attacker is able to insert spoofed IP 
packets or DNS packets when the service manager sends requests to the original Service 
Market site, the service manager can be sent to a site with malicious services. 


T2. Tampering: An attacker can inject code for replacing integrity check of installed services. 
This will lead to malicious services being installed, which were not verified by the service market 
controller. 


T3. Repudiation: Someone rejects installation of a service in order to deny possible payment 
for energy bill. 


T4. Information disclosure: An attacker is able to see the intellectual property of a service. 


T5. Denial of service: If an attacker can block any communication with the service manager, 
the service manager cannot update installed services. 


T6. Elevation of privileges: The HEMS supports third-party services to be installed through 
the service market provider. If the service market provider is able to install a service that is able to 
access outside the boundary of its privileges, an attacker can access the meter data, smart device 
configurations. 


3.5.3. Attack trees 


Attack trees are useful for visualising the escalation of attacks (see Figure 6). The attack tree 
shows the root cause of an attack and what an attack subsequently after would allow an 
attacker to do. What would seem to be a minor attack on the system can propagate through 
the system, leaving assets exposed for an attacker. 


In the following, the threats towards the process with the lowest trust boundary is focussed 
on for brevity; the “Third-party HEM service” (where the MDM service is a special case). The 
threats T1, T2, T4, T5 and T6 can be collected from the root threat “Install of malicious service”. 
The root of the attack tree is set to this threat. It is presented with the problematic state as root. 
Each edge in the attack tree is labelled with “{noticeable/likelihood}” measure, to indicate if 
the attack is believed to be noticeable and the likelihood of such an approach (Figure 6). 


4. Mitigation strategies 


Often the time spend on judging the level of the risk should be compared to the time for 
addressing the threat. When addressing the threat, it is possible to mitigate the risk by 
redesigning of system architecture, implementing a mitigation feature or simply ignoring it. 
In the following, the chapter will review for hardware security and privacy mechanisms that 
mitigate the “install of malicious service” attack. 


° The term “someone” instead of attacker is used deliberately, since it can represent the user of the system as well. 
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4.1. Security and privacy technologies 


The process of developing a secure hardware platform has recently intensified. Previously, 
computer security primarily focussed on creating secure software architectures and protocols 
with the assumption that the lower-layer applications (e.g., the OS) would be secure. However, 
flaws in an OS implementation can likely lead to additional vulnerability of the application on 
top of it. Therefore, researchers have proposed systems for running trusted code on an 
untrusted OS, but there exists still pitfalls, for example, Iago attacks [22]. In the following, the 
concept of a Trusted Execution Environment (TEE) will be reviewed as well as technologies 
that use this concept. 


4.1.1. Trusted execution environments 


In its essence, a TEE is an environment that you can choose to rely upon to perform sensitive 
tasks. The goal of TEE is to provide an isolated execution environment, secure storage, remote 
attestation, secure provisioning and a trusted path [23]. In hardware, it usually defines a 
distinguished part of the hardware architecture which is encrypted and integrity protected. It 
isolates an area of the processor, memory and peripherals for performing privileged opera- 
tions. Next to the TEE, a Rich Execution Environment (REE) is considered outside the Trusted 
Computing Base (TCB), where both an untrusted OS and untrusted third-party services can 
be executed. Despite its realisation in AMD Secure Execution Environment, ARM's TrustZone 
technology [24], and Intel's SafeGuard Extensions (SGX) [25], it is not widely used by service 
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Figure 6. Attacks based on threats towards “Third-party HEM service”. 
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developers. In the following, we will examine the hardware security technologies for mitigat- 
ing the identified risk in Section 3.4. 


4.1.1.1. ARM TrustZone technology 


The security extensions embedded in the specification of ARMv6 and later are called the 
TrustZone technology [24]. It provides two operational worlds: a normal world and secure 
world. This allows for different execution privileges for applications. For instance, an applica- 
tion responsible for handling confidential data can be executed in the secure world, without a 
normal application being aware about; even with vulnerabilities in the normal world's OS. The 
two worlds are executed through two virtual processors with hardware access controls to 
switch between the two worlds. The hardware access switch defines the active components in 
the hardware when switched. Traditionally, ARM TrustZone has primarily been used for 
Digital Rights Management (DRM) or banking applications, but are not restricted to those 
types of applications. 


4.1.1.2. Intel SGX 


Intel's SGX extension is a set of instructions and mechanisms for managing the memory access 
to the Intel Architecture processors [25]. The main principle relies upon the concept of a 
protected memory container, also referred to as an enclave. The enclave can be created through 
application code, where sensitive data are explicitly marked. When the application is executed, 
a sensitive part of the application's memory space is encapsulated within an enclave. This 
enclave ensures that the confidentially and integrity of that memory space are sustained even 
with the presence of privileged malware (i.e., super-user capabilities). Furthermore, to ensure 
the integrity of the application inside the enclave, Intel SGX supports CPU-based attestation 
and sealing. An audited process monitors the built process of the enclave and assesses the 
identity of the hardware from where the enclave should be executed. Before the application is 
executed of the CPU, the identity of the hardware is verified through the sealing identity. It 
contains a digital signature (known as report) of the enclave's initial state. The enclave is then 
capable of receiving a report of the state, verifying its correctness. To verify that the correct 
software has been instantiated on the platform to remote system, it can perform an attestation 
with the SGX-supported processor (known as quote). This can prove to a remote system that 
application has been sent to a genuine SGX implementation. The reader is referred to [26] for 
a thorough description of the Intel SGX technology. 


4.1.1.3. TrustLite and TyTAN 


TrustLite [27] is a security architecture for resource constrained embedded systems that 
generally have to be cost effective in terms of development and production costs. The archi- 
tecture allows for software isolation with execution-aware memory protection. The memory 
protection enforces a strict access control on memory by considering the program counter. 
Furthermore, it includes a secure exception engine that protects tasks from unauthorised 
exception handling. It has a secure loader that enables update of the security policy as well as 
prevents memory leakages after resetting the platform. However, TrustLite is static in terms 
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of loading software components and their isolation, since this is required at boot time. TyTAN 
[28] leverages the TrustLite architecture for providing dynamically loading software compo- 
nents together with an integrated real-time system. 


4.1.1.4. Haven 


The objective of Haven security architecture [29] is to protect the confidentiality and integrity 
of auser's unmodified application in the cloud from an untrusted cloud provider. It is assumed 
that the processor is implemented correctly, but otherwise it is assumed that the adversary can 
access everything else, including memory and I/O devices. On software level, it is assumed 
that the adversary has full access to the entire software stack, including the OS, hypervisor, 
Basic Input/Output System (BIOS), device firmware and so on. 


The inventors of Haven solve the confidentiality and integrity problem by using an inverse 
sandboxing technique also known as a shielded execution. Their solution is called Haven, and it 
leverages the Intel SGX and Microsoft's Drawbridge project [30]. Intel SGX allows application 
developers to protect their data from unauthorised access or modification by software that 
have highest privilege levels (e.g., a super-user). 


The deployment process of the Haven application is similar to the deployment of a regular 
cloud application, with the additional step of verifying that the process was correctly per- 
formed (the attestation from the Intel CPU). It is assumed that the cloud provider provides an 
Infrastructure as a Service (laaS), that delivers the storage, hardware and networking compo- 
nents on a virtualisation platform (e.g., KVM, Xen, etc.). 


4.2. Recommendations and conclusion 


Recommendations for a HEMP provider are given based on the vulnerabilities discovered 
from the threat model and the review of hardware security technologies based on TEE. Some 
of these recommendations reflect the challenges the security community and the hardware 
manufacturers are facing today, thus implementation details are still unexplored. Therefore, 
this chapter limits the thoroughness of recommendations to a problem description and 
possible approaches that need to be adapted for the HEMS. The problem description is linked 
to the identified requirements and threats, where the approaches are linked to the hardware 
technology review. The list of recommendations is as follows: 


° The HEMP should support isolation of services in terms of data and resources: At the 
service layer envisioned for the HEMS, software frameworks for energy management 
already provide isolation of services (e.g., OSGi-based software frameworks). However, as 
services become mission critical in relation to energy management, the computational 
resources must also be isolated. Furthermore, as services need different privileges for 
accessing data, the HEMS should provide a data isolation mechanism. An application 
isolation mechanism based on the TyTAN security architecture [28] could comply with such 
demands. Furthermore, it allows the use of real-time-dependent intelligent automation 
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services and allows for securely installing additional communication drivers (see R1, R2, 
R6, R7 R9, R10, R11). 


° The HEMP could provide an inverse sandboxing mechanism, if the deployment of a 
service is sensitive for access or modification by highest privileged users: Acting as a 
platform for intelligent automation services to be deployed on, the service provider might 
have contractual agreement with the residential consumer about their electricity consump- 
tion. For achieving this, the service providers must ensure the integrity and confidentially 
of the intelligent automation services. This can be achieved, for example, by using the inverse 
sandboxing mechanism that the Haven [91] security architecture provides (see R5). 


° The HEMP should place the device authentication process and the update process in a 
trusted environments and vulnerable data in a secure data storage (e.g., containing private 
keys) Authentication becomes a larger problem in the smart grid because of the necessity 
of self-organisation. A possible solution is presented in [31] which is based on TEE (see R3, 
R4, R7, R8). 


Constructing a HEMP, which is both secure and ensures the privacy of considered data assets, 
is challenging. But in order to do so, an important property for enforcing security is to build it 
in the system and not onto the system. This chapter contributes with a threat modelling of 
HEMS based on the requirement and design phases of the Microsoft Security Development 
Lifecycle. A domain model is constructed using UML, and the requirements are elicited from 
use cases for HEMS under research. A DFD models an abstract HEMS platform based on a 
combination of the architecture of OGEMA framework and reference architecture of a mobile 
platform [32]. Based ona threat analysis of the DFD, an attack tree is constructed with the focus 
ona malicious service attacker. Given the threats, mitigation strategies are reviewed for giving 
recommendations for HEMP manufacturers in the future smart grid. 
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